-
Notifications
You must be signed in to change notification settings - Fork 592
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ERC: Extended Multiphase Fractional NFTs #344
base: master
Are you sure you want to change the base?
Conversation
The commit 469057e (as a parent of 38751ef) contains errors. |
ERCS/erc-9988.md
Outdated
@@ -0,0 +1,71 @@ | |||
--- | |||
eip: 9988 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eip: 9988 | |
eip: 7661 |
Assigning next sequential EIP/ERC/RIP number.
Numbering changed to sequential from 7500.
Please also update the filename.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've already bought the domain name & hosted the website though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've already been posting about it aswell. I don't get why I have to change it when there are randomly chosen EIP numbers.
ERCS/erc-9988.md
Outdated
title: Extended Multiphase Fractional NFTs | ||
description: Allows for ERC-721 tokens to be broken into multiple phases of fungible tokens | ||
author: Jonathan Else (@JEflyer) | ||
discussions-to: https://ethereum-magicians.org/t/erc-9988-xmf-nfts-extended-multiphase-fractional-nfts/19346 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussions-to: https://ethereum-magicians.org/t/erc-9988-xmf-nfts-extended-multiphase-fractional-nfts/19346 | |
discussions-to: https://ethereum-magicians.org/t/erc-7661-xmf-nfts-extended-multiphase-fractional-nfts/19346 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EIP numbers are assigned (roughly) sequentially. You cannot request specific ones.
ERCS/erc-7661.md
Outdated
An extension of the [ERC-721 standard](./eip-721.md) to enable [ERC-721](./eip-721.md) tokens to have multiple phases of fractionalisation into [ERC-20](./eip-20.md) like tokens. | ||
|
||
This standard introduces a framework allowing [ERC-721](./eip-721.md) Non-Fungible Tokens (NFTs) to be broken down into phase-based tokens (PB Tokens) representing fractional ownership or states at various lifecycle phases. Unlike standard [ERC-20](./eip-20.md) tokens, PB Tokens accommodate the multifaceted nature of asset transformation, encapsulating phase transitions that reflect changes in the underlying asset's state, form, or value. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be nice if your abstract included a bit more detail on how your proposal accomplishes its goals. Are PB tokens ERC-20s themselves, or are they a new thing? What are phases?
The Abstract should give the reader a high-level technical overview of the whole proposal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you read the contracts you can see the implementation. https://github.com/JEflyer/ERC9988/blob/main/contracts/ERC9988.sol
They are a new type of token, because of the multiphase aspect of the standard they can't be ERC20 because they don't adhere to the interface requirements of ERC20.
This is my first standard I've made, what would you recommend that I put for this standard?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm only lightly familiar with tokens, and am here to provide mostly editorial feedback 😅 Maybe you could include some examples of what a "phase" might be, and explain in what scenarios your standard is more useful than say ERC-7651 or ERC-4675.
To be clear, these are suggestions for content to be added to the document itself.
|
||
## Motivation | ||
|
||
In industries involving supply chains or assets undergoing various forms of processing, a singular representation (as either a fungible or non-fungible token) falls short of depicting the asset's evolving nature. This standard addresses this gap by enabling dynamic representation and management of assets throughout their transformation phases, enhancing tracking and interaction with these assets on the blockchain. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you include some example use cases or assets that you think would be particularly suited to being represented as PB tokens?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The best usecase that I could think of was a pallet of 1 item that break down into boxes of items & then individual items.
I put an example on the explainer website. https://www.erc9988.info/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you don't have a particular use case you're building towards, perhaps it's a bit early to standardize?
- PB Tokens are associated with an ERC-721 NFT, representing fractional ownership or specific attributes of the NFT in a given phase. | ||
- Each PB Token phase reflects a distinct state or condition of the underlying asset, with the contract managing transitions between these phases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These aren't really implementable requirements, or at least they aren't phrased as such. Content in the specification section should have specific criteria that implementations can be judged against.
|
||
## Rationale | ||
|
||
Introducing this standard fills a critical niche, blending the characteristics of ERC-721 and ERC-20 tokens to accurately represent dynamic assets. This standard is particularly suited for applications requiring detailed asset management through various phases of transformation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This content belongs in the Motivation section. The Rationale section is here so you can explain why you made the choices you did while developing your standard. My favourite analogy is:
Motivation: We need to build a shed because...
Rationale: We painted the shed red because...
|
||
## Reference Implementation | ||
|
||
An implementation can be found here: `https://github.com/JEflyer/ERC9988` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove this external link. You can include a reference implementation in the assets/
directory if you'd like.
Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com>
There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met: